FIG. 1 illustrates an example of two wireless devices using a “direct mode” of communication, based on the two devices being in relatively close proximity to one another. In an example case, the two devices are referred to as user equipments, or UEs. Each UE is configured for operation in a Third Generation Partnership Project (3GPP) communication network, e.g., a cellular communication network based on the Long Term Evolution (LTE) specifications. Further, each UE is configured for Device-to-Device (D2D) communications, which allows each device to talk to other devices having compatible D2D communication capabilities. D2D communications may be network-assisted when one or both devices are operating within the coverage of the cellular network.
FIG. 2 illustrates a variation on D2D communications between the two devices. This variation is referred to as “locally-routed” communications, in that the signaling between the two devices is conveyed through a serving base station—eNodeB in LTE. However, unlike conventional cellular communication signaling between two devices, the signaling is not routed through the default path, which includes the “core network” of the supporting cellular communication network. See FIG. 3 for an example of this conventional default-path routing case, where signaling between two devices is communicated through serving gateway (SGW)/packet gateway (PGW) nodes in the core network associated with the Radio Access Network (RAN) supporting the two UEs.
In device-to-device communication, the source and the target are wireless devices, e.g., UEs. Some of the potential advantages are offloading of the cellular network, faster communication, increased awareness of surrounding wireless devices of interest (e.g., running the same application), higher-quality links due to a shorter distance, etc. Some appealing applications of D2D communications are video streaming, online gaming, media downloading, peer-to-peer (P2P), file sharing, etc.
FIG. 4 illustrates a reference architecture for D2D operations, where “ProSe” denotes “Proximity Services,” and indicates services available via D2D communication between devices in proximity to one another. See the 3GPP Technical Reference, TR 22.803, Feasibility study for Proximity Services (ProSe), for example details regarding this architecture, and the above-described direct communications, locally routed communications, and default-path communications. Further, in the context of FIG. 4, “APP” denotes application, “E-UTRAN” denotes an Evolved Universal Terrestrial Radio Access Network, as used for the radio access part of LTE. “EPC” denotes Evolved Packet Core, as used for the core network part of LTE.
Numerous challenges attend the effective integration of D2D communications capability into the overall communication system framework. For example, it is recognized herein that “Discontinuous Reception” (DRX) presents a number of challenges and opportunities with respect to D2D-capable wireless devices. Discontinuous Reception (DRX) has been introduced as one of the key solutions for conserving battery power in wireless devices operating within a wireless communication network.
In the LTE example case, DRX is characterized by the following:                Per UE mechanism (as opposed to per radio bearer);        May be used in RRC_IDLE and RRC_CONNECTED; In RRC_CONNECTED, eNodeB/UE may initiate the DRX mode when there are no outstanding/new packets to be transmitted/received; in RRC_IDLE                    2G and 3G terminal use discontinuous reception in idle state to increase battery life time. HSPA and LTE have introduced DRX also for connected state                        Available DRX values are controlled by the network and start from non-DRX up to 2.56 seconds in LTE in RRC connected state. Even longer DRX cycles may be introduced in the future.        HARQ operation related to data transmission is independent of DRX operation and the UE wakes up to read the PDCCH for possible retransmissions and/or ACK/NAK signalling regardless of DRX In the downlink, a timer is used to limit the time the UE stays awake awaiting for a retransmission;        When DRX is configured, the UE may be further configured with an “on-duration” timer during which time the UE monitors the PDCCHs for possible allocations;        When DRX is configured, periodic CQI reports can only be sent by the UE during the “active-time”. RRC can further restrict periodic CQI reports so that they are only sent during the on-duration;        Network node (e.g., eNodeB) does not transmit packets to UE during the sleep mode.        
RRC_CONNECTED mode DRX should not be mixed up with DRX in idle mode which the mobile is set into after a prolonged time of air interface inactivity. Its also known as paging DRX, i.e. the time the mobile device can go to sleep between two paging messages which could contain a command for the mobile to wake up again and change back to RRC_CONNECTED state. In the RRC connected state, the possible DRX cycles vary from very short DRX cycle lengths (e.g. 2 ms), to much longer DRX cycle lengths (e.g., hundreds of milliseconds or even seconds, such as 2.56 s).
Parameters Related to DRX
The following definitions apply to DRX in E-UTRAN:                on-duration: duration in downlink subframes that the UE waits for, after waking up from DRX, to receive PDCCHs. If the UE successfully decodes a PDCCH, the UE stays awake and starts the inactivity timer;        inactivity-timer: duration in downlink subframes that the UE waits to successfully decode a PDCCH, from the last successful decoding of a PDCCH, failing which it re-enters DRX. The UE shall restart the inactivity timer following a single successful decoding of a PDCCH for a first transmission only (i.e. not for retransmissions).        active-time: total duration that the UE is awake. This includes the “on-duration” of the DRX cycle, the time UE is performing continuous reception while the inactivity timer has not expired and the time UE is performing continuous reception while waiting for a DL retransmission after one HARQ RTT. Based on the above the minimum active time is of length equal to on-duration, and the maximum is undefined (infinite).        
Of the above parameters the on-duration and inactivity-timer are of fixed lengths, while the active-time is of varying lengths based on scheduling decision and UE decoding success. Only on-duration and inactivity-timer duration are signaled to the UE by the network node (e.g., an eNodeB):                There is only one DRX configuration applied in the UE at any time;        UE shall apply an on-duration on wake-up from DRX sleep.        
DRX mode in LTE is illustrated in FIG. 5. DRX is triggered by means of an inactivity time known as DRX. As can be seen from FIG. 5, the UE activity time may be extended if PDCCH is received during ON Duration time. However, it may also be shorten by a MAC DRX command, upon reception of which the UE stops onDurationTimer and drx-InactivityTimer.
If PDCCH has not been successfully decoded during the on-duration, the UE shall follow the DRX configuration (i.e. the UE can enter DRX sleep if allowed by the DRX configuration):                This applies also for the sub-frames where the UE has been allocated predefined resources.        If it successfully decodes a PDCCH for a first transmission, the UE shall stay awake and start the inactivity timer (even if a PDCCH is successfully decoded in the sub-frames where the UE has also been allocated predefined resources) until a MAC control message tells the UE to re-enter DRX, or until the inactivity timer expires. In both cases, the DRX cycle that the UE follows after re-entering DRX is given by the following rules:                    If a short DRX cycle is configured, the UE first follows the short DRX cycle and after a longer period of inactivity the UE follows the long DRX cycle; if short DRX cycle is used, the long cycle will be a multiple of the short cycle;                            Durations for long and short DRX are configured by the RRC. The transition between the short and long DRX cycles is determined by the eNodeB MAC commands (if the command is received and short DRX is configured, the UE will (re)start drxShortCycleTimer and use the Short DRX Cycle; otherwise long DRX will be used) or by the UE based on an activity timer                                    Else the UE follows the long DRX cycle directly.                        
Some parameters that may be configured by the network:                onDurationTimer can be (in PDCCH subframes): 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, and 200        drx-InactivityTimer can be (in PDCCH subframes): 1, 2, 3, 4, 5, 6, 8, 10, 20, 30, 40, 50, 60, 80, 100, 200, 300, 500, 750, 1280, 1920, 2560. A specific value may also be configured if the UE supports IDC (in-device co-existence)        longDRX-CycleStartOffset (in subframes): depending on the cycle length, but up to 2559        shortDRX-cycle (in subframes): 2, 5, 8, 10, 16, 20, 32, 40, 64, 80, 128, 160, 256, 320, 52, 640        
UE Active Time and UE Transmissions when Using DRX
When a DRX cycle is configured, the Active Time includes the time while:                onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or mac-ContentionResolutionTimer is running; or        a Scheduling Request is sent on PUCCH and is pending; or        an uplink grant for a pending HARQ retransmission can occur and there is data in the corresponding HARQ buffer; or        a PDCCH indicating a new transmission addressed to the C-RNTI of the UE has not been received after successful reception of a Random Access Response for the preamble not selected by the UE.        
Generally, new transmissions can only take place during the active-time (so that when the UE is waiting for one retransmission only, it does not have to be “awake” during the RTT).
When not in Active Time, type-0-triggered SRS [2] shall not be reported.
If CQI masking (cqi-Mask) is setup by upper layers:                when onDurationTimer is not running, CQI/PMI/RI/PTI on PUCCH shall not be reported,else:        when not in Active Time, CQI/PMI/RI/PTI on PUCCH shall not be reported.        
That is, cqi-Mask is effectively limiting CQI/PMI/PTI/RI reports to the on-duration period of the DRX cycle, and the same one value applies for all serving cells (the associated functionality is common i.e. not performed independently for each cell).
There are a few exceptions:                Regardless of whether the UE is monitoring PDCCH or not, the UE receives and transmits HARQ feedback and transmits type-1-triggered SRS when such is expected.        A UE may optionally choose to not send CQI/PMI/RI/PTI reports on PUCCH and/or type-0-triggered SRS transmissions for up to 4 subframes following a PDCCH indicating a new transmission (UL or DL) received in subframe n-i, where n is the last subframe of Active Time and i is an integer value from 0 to 3. After Active Time is stopped due to the reception of a PDCCH or a MAC control element a UE may optionally choose to continue sending CQI/PMI/RI/PTI reports on PUCCH and/or SRS transmissions for up to 4 subframes. The choice not to send CQI/PMI/RI/PTI reports on PUCCH and/or type-0-triggered SRS transmissions is not applicable for subframes where onDurationTimer is running and is not applicable for subframes n-i to n.        
Problems with Existing Solutions
The network may be not aware of the UE's D2D activity and therefore the UE's DRX may be configured by the network without accounting for its D2D activity.